Software Vault: The Gold Collection

home *** CD-ROM | disk | FTP | other *** search

/ Software Vault: The Gold Collection / Software Vault - The Gold Collection (American Databankers) (1993).ISO / cdr28 / mwftpd.zip / MANUAL.TXT < prev next >

Wrap

Text File | 1993-03-06 | 64KB | 1,423 lines

FTPD An FTP Daemon NLM for Novell Netware 386 3.11 Administrators Guide Copyright (C) 1992 MurkWorks All Rights Reserved August 9, 1992 MurkWorks P.O. Box 631 Potsdam, NY 13676 USA info@murkworks.com FTPD V1.31 Administrators Guide Copyright 1992 MurkWorks All Rights Reserved This software is not shareware, freeware nor public domain. It has been provided to you in a limited timed demo format. You may use this software without obligation until the demonstration period expires. When the demonstration period has expired, the software will no longer function. If you wish to continue to use the software you must register it with MurkWorks and pay a per server license fee. See the accompanying order form for pricing and ordering information. Dis- assembly or patching of the software to provide execution beyond the end of the demonstration period is expressly forbidden. Demo Version -- No Warranty MurkWorks makes no warranty of fitness or suitability for a particular purpose. Although we have made every effort to ensure the reliable and satisfactory operation of this software, we do not warrant it in any way. You the user assume all responsibility in its use and operation. MurkWorks shall not be held liable for any loss of any kind. Licensed Version -- Limited Warranty If you have registered your copy of the software and paid a license fee to MurkWorks, this software is covered by a limited warranty for the first sixty (60) days from the date of receipt of the license fee. Should the software fail or prove unsatisfactory during that time period MurkWorks sole remedy to you will be the reimbursement of your license fee. In no event will MurkWorks be held liable to you for any damages, including lost profits, lost savings or other incidental or consequential damages arising out of the use of this software or the inability to use this software. Trademarks Novell and Netware are registered trademarks, and Netware NLM, and Netware Loadable Module are trademarks of Novell, Inc. Other computer and software names are registered trademarks of their respective manufacturers. This product was developed using Network C for NLMs , Novell 's toolkit for developing server-based applications for the Netware 3.x operating system. Additional Information For additional information, write to us via postal mail: MurkWorks P.O. Box 631 Potsdam, NY 13676 USA Or send electronic mail to info@MurkWorks.com Table of Contents Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1 Features . . . . . . . . . . . . . . . . . . . . . . . . 1 System Requirements . . . . . . . . . . . . . . . . . . 2 Installation . . . . . . . . . . . . . . . . . . . . . . . . 2 Quick Start . . . . . . . . . . . . . . . . . . . . . . 2 Standard Installation . . . . . . . . . . . . . . . . . 3 Configuration File . . . . . . . . . . . . . . . . . . . . . 3 Class Definitions . . . . . . . . . . . . . . . . . . . 3 Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 Access Settings . . . . . . . . . . . . . . . . . . . . 4 log . . . . . . . . . . . . . . . . . . . . . . . . 5 logfile . . . . . . . . . . . . . . . . . . . . . . 5 connect . . . . . . . . . . . . . . . . . . . . . . 5 idle . . . . . . . . . . . . . . . . . . . . . . . 5 timerange . . . . . . . . . . . . . . . . . . . . . 6 Deny . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Allow . . . . . . . . . . . . . . . . . . . . . . . . . 7 Deny/Allow Ordering . . . . . . . . . . . . . . . . . . 7 MaxConnections . . . . . . . . . . . . . . . . . . . . . 8 ScreenDelay . . . . . . . . . . . . . . . . . . . . . . 8 LogFile . . . . . . . . . . . . . . . . . . . . . . . . 8 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Command Line Options . . . . . . . . . . . . . . . . . . 10 Console Commands . . . . . . . . . . . . . . . . . . . . 10 Monitor Display . . . . . . . . . . . . . . . . . . . . 11 Home Directories . . . . . . . . . . . . . . . . . . . . 13 User Commands . . . . . . . . . . . . . . . . . . . . . 13 Anonymous Accounts . . . . . . . . . . . . . . . . . . . 14 Proxy Connections . . . . . . . . . . . . . . . . . . . 15 Security Considerations . . . . . . . . . . . . . . . . 15 Performance . . . . . . . . . . . . . . . . . . . . . . . . . 18 How We Test . . . . . . . . . . . . . . . . . . . . . . 18 Memory Requirements . . . . . . . . . . . . . . . . . . 18 Processor Utilization . . . . . . . . . . . . . . . . . 19 How to Get Support . . . . . . . . . . . . . . . . . . . . . 21 Appendix A Sample Configuration File . . . . . . . . 22 Appendix B Supported FTP Commands . . . . . . . . 24 1 Introduction Welcome to MurkWorks FTP Daemon NLM for Netware 386. This product provides an efficient and useful FTP daemon NLM for your Netware 386 server. FTP (File Transfer Protocol) is described in RFC959. It provides a mechanism for internet hosts to transfer files in text or binary mode between cooperating systems. FTPD V1.31 supports the most common commands listed in RFC959. For a complete list of supported commands see appendix B. This manual assumes that you have a basic understanding of the TCP/IP protocol and a thorough understanding of the NW386 environment. If you do not currently have the TCPIP.NLM module loaded on your Netware server, now would be a good time to review the TCP/IP Transport Supervisor's Guide provided with the NW386 3.11 manual set. Features FTPD.NLM supports the following features: Multiple simultaneous service connections Real-time monitor display Transaction logging Access control by remote IP address, target server and user Supports NW2.15 servers through `proxy' ftp service Anonymous connections Idle and connect timeouts, restricted access times, etc 2 System Requirements NLMS The FTPD NLM uses both CLIB.NLM and the TCPIP.NLM. When loading the TCPIP.NLM, CLIB will be automatically loaded. Follow the procedures outlined in the TCP/IP Transport Supervisor's Guide when installing and configuring the TCPIP nlm. You will need to provide at least one IP address for your Netware server. MEMORY A typical Netware 386 server with 4 megabytes of RAM is quite sufficient to operate the FTPD NLM. A detailed analysis of the memory required per connection is described in the Performance section of this manual. Installation Quick Start If you're impatient and don't want to read through this manual, follow the instructions in this section to get the NLM up and running as quickly as possible. Without a configuration file, the FTPD NLM will not provide any access control beyond standard Novell password checking. This may be sufficient for your needs. You can always follow the full installation instructions later if you so desire. This program is distributed with the file: ftpd.nlm - The FTPD NLM If you have licensed your copy of the FTPD NLM, you will have also received the file: ftpd.key - Security key file To install the FTPD NLM on your Netware 386 server, log into the server as supervisor and copy the ftpd.nlm file to sys:system. If you have licensed your copy, you should also copy the file ftpd.key to sys:system. If you're in a hurry, load the FTPD NLM by issuing the follow command on the NW386 console: load ftpd otherwise, create a configuration file as described in the Configuration File section before loading the NLM 3 with the load command. Standard Installation If you wish to make use of the additional security features of the FTPD NLM, you will have to create a configuration file. The next section of this manual describes how to create a configuration file. After creating the configuration file, follow the instructions described in the Quick Start section shown above. Configuration File The file ftpd.cfg is provided in the distribution as an example only. Do not copy this file into the sys:system directory. Instead, you should print this file on a printer and use it as a reference when creating your own ftpd.cfg file. This sample file is also listed in the appendix of this manual. The configuration file uses a simple ASCII format with one command per line. Lines which begin with the pound symbol (#) are comment lines and are ignored. Use a suitable text editor to create a file called ftpd.cfg in the sys:system directory. This file will control how the FTPD NLM operates. Read this section carefully to get the most out of your software. If you create a new ftpd.cfg file or alter an existing one, you will have to either reload the FTPD NLM or issue the ftpd reconfig command before the changes will take effect. Class Definitions When a remote client connects to the FTPD NLM for service, its internet address (IP Address) or internet name can be used to place it in an access class. This allows connections to be grouped based on whether they are `local' or `remote'. For example, a university may wish to have one access class defined for on campus clients, and a second one defined for off campus users. Classes can have a list of valid servers and users, as well as default settings for transaction logging, time limits and so forth. 4 A new class is defined with the class command, as follows class classname where classname is the name of the class. This name may be anything meaningful to the supervisor. There is one special class whose name is default. This class is used whenever an incoming connection does not match any other listed class. Addresses Following the class command is a list of access control commands and the class definition command: address. The address command controls which remote connections are grouped into the specified class. The address command takes one argument, an IP Address or IP Name: address 129.134.*.* address *.murkworks.com The address command must follow a class command, and may appear more than once in a given class. The asterix (*) indicates a wild-card pattern, which means any value may occupy its space. The address command is not allowed in the default class. When a client connects to the FTPD NLM, the class list is searched for a match. The first class found which has an address pattern that matches the client's IP address or name is used for access control. Novell Netware 386 keeps its IP Name to IP Address mapping information in the file sys:etc/hosts This file may not contain all internet names and addresses. Therefore it is important to specify an IP address in addition to the IP name. If the client's IP name is not listed in the hosts file, the FTPD NLM will use the client's IP address to match against. Access Settings Each class may have default access control settings. The settings command determines how clients may access the Netware server. The settings command has its own sub-commands, which generally appear as follows: settings [sub-commands] 5 Where [sub-commands] may be one or more of the following: Command Argument log count logfile log_file_name connect connect_time_in_minutes idle idle_timeout_in_minutes timerange allowed_access_timerange readonly All sub-commands and their arguments should appear on the same line as the settings command, however settings can be continued on the next line by inserting a plus symbol (+) at the end of each continued line. The plus symbol may not appear between sub-commands and their arguments. See the sample configuration file for an example of setting continuations. The log count setting indicates that client transactions for this class should be logged to the logfile. The number of transactions to be logged is not to exceed count entries. When this setting is in effect, transactions such as login, logout, read, write, delete, rmdir and mkdir are recorded in the log file sys:system\ftpd.log. If you only want a record of login and logout times, use a log count of zero (0). Example: log 0 The logfile setting specifies the name of the file in which log entries should be stored for this class. This setting over-rides the system-wide setting logfile (see below) if specified. The file name must be a fully specified name which includes the volume name. Example: logfile vol1:usr/anon/logfile.log The connect connect_time_limit command specifies the maximum connect time for any client in this class. After the time limit expires, the client will receive an error message and be automatically disconnected by the server at the completion of any pending command. The time limit is specified in minutes. The limited demo version of the NLM enforces a maximum connect time of five minutes. The idle idle_timeout_limit specifies the maximum idle time allowed for any client in this class. If the client does not issue a command within the idle time limit, the client will receive an error message and be 6 automatically disconnected. This command is useful in eliminating `dead' connections due to failed internet connectivity. However, too short of an idle timeout may cause unintended service disruption to the client. The time limit is specified in minutes. The timerange allowed_access_timerange controls when clients within this class may access the Novell Netware server. The format of allowed_access_timerange is: timerange startday-endday/starthour-endhour For example: timerange mon-fri/8-17 In the above example, clients are allowed access monday through friday from 8am to 5pm. The timerange command may be specified multiple times if desired. The readonly command specifies that all clients within this class have readonly access to the Novell Netware server. Even if a particular user has trustee rights which grant him write access, this setting disables all commands which may alter data on the server. Deny The deny command lists those servers and/or users who should be denied access within this class. The format of the command is: deny [server/]user Where server/ is an optional server name. If the server is not specified, it applies to the server on which the FTPD NLM is operating. Both server and user may be the wildcard (*), meaning all servers or all users respectively. For example, suppose you had defined a class for all local clients. That class would have no restrictions of any kind. You may then wish to add access restrictions for the default class which would apply to any non- local client. If you don't want to allow any non-local clients to have access to any of your Novell Servers, you could issue the following two commands in the configuration file: class default deny */* 7 Allow The allow command lists those servers and/or users which should be allowed access within this class. This command over-rides any previous deny command. The format of the command is: allow [server/]user optional settings Where server/ is an optional server name. If the server is not specified, it applies to the server on which the FTPD NLM is operating. Both server and user may be the wildcard (*), meaning all servers or all users respectively. The optional settings argument is a list of settings sub-commands which should be applied to this server/user. If any optional settings sub-commands are listed, then all settings for the class are ignored for this user. Therefore any settings which apply to the class, which should also apply to the server/user must be repeated on this line. For example, suppose a particular class had a setting timerange of mon-fri/8-17 If you wanted to grant readonly access for a particular user but maintain the timerange, the class definition would look something like the following: class example settings timerange mon-fri/8-17 allow FS1/guest readonly, timerange mon-fri/8-17 If the timerange command were not repeated on the allow line, then the user FS1/guest would not have any timerange limit because any setting sub-command on the allow command line overrides all setting sub-commands for the class. Deny/Allow Ordering The order of the deny and allow commands within the class is important. All class definitions begin with an implied allow */*. Access checking follows the list of deny/allow commands in the order in which they are encountered within the configuration file. Deny commands mask out access, where allow commands add in access. The first deny command which explicitely matches the target userid terminates the search. Wildcard deny's do not terminate the search, instead 8 subsequent wildcard allows or explicit allows may over- ride the previously encountered deny command. When the last deny/allow command is encountered in the class, the logical result determines whether or not access is allowed and which settings are applied. For example, if you wanted to grant all users access to a particular server with readonly access, but you wanted the supervisor to have full access, the following would be a possible configuration file entry. allow */* readonly allow */supervisor If the order of the above commands were reversed, the supervisor would have readonly access because the */* mask also applies to the supervisor. MaxConnections This command specifies the maximum number of simultaneous client connections. For the limited timed demo version of this program, the maximum number of connections is silently forced to two (2) or less. In the licensed version, the maximum number of connections is thirty-two (32). If this command is not specified, the default number of connections is (2) in the limited timed demo version, and (5) in the licensed version. Example: maxconnections 3 ScreenDelay This command specifies the number of seconds between monitor screen updates. If this command is not specified, the default is (2) seconds between screen refreshes. The minimum allowable value is (1). Too low a value may increase server utilization if there are many active connections. A value between (2) and (5) is recommended. Example: screendelay 5 LogFile 9 This command specifies the name of the system-wide log file. The system-wide logfile is where transactions will be logged for those users or classes for which no logfile command has been specified. The logfile name must be the full-path name of the log file. If this command is not specified, the default is sys:system\ftpd.log Example: logfile sys:system\access.log 10 Operation Command Line Options The FTPD NLM recognizes several command line arguments which can be provided during the load phase. /config config_file Specifies the path to an alternate configuration file, instead of the default sys:system\ftpd.cfg /keyfile key_file Specifies the path to an alternate key file instead of the default sys:system\ftpd.key /delay delay_time Specifies the monitor screen update delay in seconds. Overrides any value specified in the configuration file. /max count Specifies the maximum number of connections. Overrides any value specified in the configuration file. /display Enables the monitor display. By default the monitor display is not shown. Using this switch causes the display to appear when the NLM is loaded. Example: load ftpd /display /delay 5 /max 3 This command line loads the FTPD NLM, enables the monitor display with an update frequency of 5 seconds and a maximum of 3 connections. Console Commands The FTPD NLM provides an additional set of console commands which can be entered at the NW386 console prompt. All of the following commands are prefixed with 11 the keyword ftpd, which indicates that the command is for the FTPD NLM. ftpd disable This console command disables new incoming connections. Current connections are not effected. ftpd enable This console command enables the FTPD, allowing additional incoming connections. ftpd serialnum This console command displays serial number and application information required to register your copy of the FTPD NLM. ftpd displayon This console command enables the monitor display. ftpd displayoff This console command disables the monitor display. ftpd delay delay_time This console command sets the monitor display delay time to delay_time seconds. ftpd reconfig config_file This console command causes the NLM to reload the configuration file. If an optional configuration file name is provided after the command, then that file is used instead of the default sys:system\ftpd.cfg This command is only allowed when there are no active connections. Monitor Display 12 The FTPD NLM provides a near real-time display of current connections. To make use of the display you must enable it either by using the /display command line option or the ftpd displayon console command. The monitor display shows the first eleven (11) connections. Each connection occupies two lines of the display. The format of the display is as follows: client_host_name | last_command | username files | bytes | Kb/sec | connect | idle_time | last arg client_host_name Displays the client host name, if known, otherwise it displays the client IP address. last_command Displays the last FTP command issued by the client. username Displays the SERVER/USERNAME under which the client has logged in. If the username corresponds to a no-password anonymous account, the symbol *A* also appears in this field. files Displays the count of files transferred by the client during this session. bytes Displays the total byte count transferred by the client during this session. KB/sec Displays the average KB/Sec for all files transferred by the client. connect Displays the total client connect time in HH:MM:SS format. idle_time Displays the current client idle time in HH:MM:SS format. 13 last_arg Displays the argument for the last FTP protocol command issued by the client. Home Directories When a client logs in to a Netware server, the FTPD NLM examines the bindery information for that userid. The NLM looks for a bindery property of the name HOME_DIR. If this bindery property is found, it executes an automatic chdir to value of that property. This provides a means to specify a `home directory' for each user. There are several freeware utilities which provide the tools required to set this value, including David Harris' SETHOME package available from most Novell oriented FTP sites and BBSs. If the HOME_DIR property is not found, the FTPD NLM scans the Trustee Paths for that userid. If any Trustee Path has a trailing directory component which matches the userid (or nearly matches) then that Trustee Path is chosen as a home directory. For example, given the account anonymous with the following Trustee Paths: sys:mail/0023023 sys:usr/anony The FTPD NLM would select the Trustee Path sys:usr/anony as the home directory for the anonymous userid. User Commands The FTPD NLM provides the usual FTP command services. This version offers one additional site specific command: site tp This site specific command causes the NLM to list the trustee paths available to the user. A typical unix client can issue this command by using the FTP client quote command: quote site tp Additionally, the user can return to their HOME_DIRECTORY by issuing the command: 14 cwd ~ The FTPD NLM recognizes the token (~) as meaning the home directory chosen for this user during the login sequence. An error message is returned if no suitable home directory could be found. Anonymous Accounts The FTPD NLM fully supports so-called `anonymous' client connections. A typical anonymous client accesses the server with the username of `anonymous', at which point the server prompts the user for an email address or other identifier instead of requesting a password. This allows users to access the server without having to know a special password. The FTPD NLM will record the user supplied address/password to the log file if logging is enabled for the anonymous account. The FTPD NLM considers any account which has no password to be an anonymous account. Therefore the actual account name `anonymous' has no special signifigance to the FTPD NLM. The following steps are recommended when setting up an anonymous account: A. Use syscon to create a user account named `anonymous' B. Remove the user from all groups (including EVERYONE) C. Create a station restriction for the account which will inhibit any workstation from logging into the account. D. Make the password for the account be empty, and do not require a password for the account. E. Make the account a trustee for a secure directory with [R F] rights only. F. Remote the account's access rights to it's sys:mail directory. G. Use the SETHOME freeware utility to set the home directory for this account to match the secure directory. When a remote user logs into the server by specifying a userid of `anonymous', they will be prompted for an email address because the FTPD NLM will realize that the account has no password. After the user provides an email address the default current directory will be set to the secure directory. 15 Proxy Connections The FTPD NLM provides `proxy' FTP service to older, non-Netware 386 servers. Security Considerations The FTPD NLM does not inherently make your Novell server less secure. It does, however, add another avenue of attack into your server. Prudent use of the FTPD.CFG file will ensure that remote users do not violate the integrity of your system. The FTPD NLM attempts to resist password cracking schemes by disconnecting any connection which enters an incorrect password three times in a row. ie:, after the third incorrectly entered password the user is disconnected and a warning message is written to the server console. Also, on the second and third login attempts (after the first incorrect password) the FTPD NLM delays the login process by three and six seconds respectively in an effort to slow down any password cracking program. If fifteen incorrect passwords are entered without an intervening correct login (on any server, for any account), then the FTPD NLM also broadcasts a warning message to all users attached to the file server. This serves to alert the supervisor or another responsible party that the file server is under attack from a password cracking program. Finally, accounts whose password has expired are denied access to the server (whereas the Netware shell would normally allow access and prompt for a new password). Following are some suggestions to improve security on your server. A. The NLM environment does not recognize station restrictions on the local server. If you have accounts that have station restrictions, and you do not wish those accounts to be able to access the server via FTP, you must explicitely deny those accounts access because the NLM can not recognize station restrictions on the local server. Station restrictions are recognized on remote servers. If a remote server specifies a station restriction for an account which should have FTP access, you must add the 16 network address of the local server to the station restriction list of the remote server. You can obtain the station address of the local server by executing the slist command from the DOS prompt and noting the address for the local server. B. Intruder detection lockout may disable an account if excessive invalid passwords are entered. The FTPD NLM attempts to access an account twice for each login, the first time with no password (to see if the account is an `anonymous' account) and the second time to actually log in the user (if a password was required). On remote servers there is no other way to determine if a password is required for an account. Therefore, for each attempted login where an invalid password is specified the NLM actually attempts two logins to the specified account. If the intruder lockout detection count value is set too low, accounts may get locked prematurely. Additionally, malicous users may intentionally issue invalid passwords in an attempt to lock an account. This problem is not specific to the FTPD NLM, as any user on a workstation may do the same thing. To avoid locking the supervisor's account or other important accounts, you should explicitely deny access to those accounts in the ftpd.cfg file. Accounts which are `denied' are immediately rejected without a login attempt. C. Be sure that users granted access via FTP have the appropriate rights to directories on the server. This is especially important with `anonymous' accounts which might accidentally be left in the EVERYONE group. Judicious use of the readonly attribute will ensure that data is not lost if password secrecy is compromised. D. Be careful if your server is reachable from the Internet or other wide-area networks. If you have, until recently, counted on the non- routed aspect of IPX for security, be aware that once connected to the Internet your 17 server becomes reachable from places you've probably never heard of. The best course of action when first enabling FTP is to deny all users, then expressly allow only those accounts which require FTP access. Of those accounts requiring access, grant readonly access to those accounts which do not need to write to the file server. E. You should maintain a logfile of all transactions, or at the very least log all login/logout activity. Examine this logfile on a periodic basis and note accesses from address which seem inappropriate. F. If you want to totally inhibit all `non- local' ftp connections, create a class for `local' addresses. In the `local' class, configure the deny/allow settings as described previously. Then create a default class which deny's all users on all servers. Example: class default deny */* class local addresses *.mydomain.com addresses 129.136.*.* deny */* allow bill allow tom settings log 10 18 Performance This section of the manual describes the memory requirements and expected performance of the FTPD NLM. It describes how we tested and developed the NLM. You do not have to read this section to make use of the FTPD NLM. How We Test The FTPD NLM was tested `in-house' on two NW386 file servers, one a 386/33 with 4 megabytes of ram, the other a 486/33 with 8 megabytes of ram. In all cases the client was a 486/33 running Dell Computer Corporation's OEM version of USL SYSVR4 Unix . A series of test `scripts' were used (the expect package for Unix implemented the scripts) which exercised all functions within the NLM, the expected return codes and the file transfer operations. These scripts were executed multiple times, simulating simultaneous clients. The scripts also repeatedly used the mget and mput operation in an effort to place the maximum load on the Netware server. All scripts were executed with the FTPD NLM running with and without protect.nlm1 Additionally, a select group of beta testers have tested this NLM in several different environments. Memory Requirements This version has the following memory requirements (values are approximate). This information was gleaned from monitor.nlm under the Resource Utilization section. Base Memory NLM size 13 K bytes Base Socket 9.5 K bytes Each Client 13 K bytes additional Monitor Screen 8 K bytes additional Each Transaction 32 bytes plus filename size Using the above information, the maximum amount of memory used by the NLM can be determined. 1Protect.nlm is provided with the Netware C for NLMS kit. This NLM detects memory accesses outside the area set aside for the NLM. 19 For example, suppose a maximum of two connections was allowed. If every client connection was to be logged with a maximum of 100 transactions each, and if the average filename size was 40 bytes, then the memory usage would be as follows: 22.5 K Base Memory 26 K Two client connections (32 + 40) * 200 Maximum log entries stored in memory ------------- 64 K bytes Total memory used The transaction entries are stored in memory until the client logs out, at which time the client thread gains back its supervisor privileges, allowing it to write to the log file in sys:system. Processor Utilization Processor utilization information was obtained by loading monitor.nlm with the -p command line option load monitor -p The test process used a 5 megabyte PostScript file for transfer. The file was read multiple times, noting the maximum utilization figure ever shown on the monitor display, along with the maximum percentage utilization per process. The Netware server was a 486/33 with 8 megabytes of Ram and an ESDI disk running through an Ultrastor 12F controller. The test file was transferred in both directions using binary and ascii mode. As expected, ascii transfer had a higher utilization due to the extra processing involved. The test was executed on a private ethernet connection, the server used a Racal-Interlan NI6510 lan card, the client (SYSVR4 Unix on 486/33) used a Western Digital (SMC) WD8003EBT lan card. Utilization is proportional to throughput. The FTPD NLM contains no throttling component, therefore it will use maximum server resources during transfers in an effort to supply the client as quickly as possible. Idle connections cause zero server utilization. However, if the monitor display is enabled and the screen update delay is low (less than 3 seconds) and 20 there are several connections, then the utilization from that component will be approximately 2 - 5 depending on screen update delay. % % % Utilizat % Client Server Utilizat Utilizat Operatio ion Utilizat Throughp Utilizat ion from ion from n from ion from ut ion LAN Card DISK FTPD TCP NLM Ints Ints Binary 330 82 13% 4% 9% 51% Put KB/sec Ascii 220 90 48% 3% 6% 30% Put KB/sec Binary 400 50 30% 4% 12% --2 Get KB/sec Ascii 190 63 58% 2% 5% -- Get KB/sec 2Get operations had negligible disk interrupts because the file had been cached in memory. 21 How to Get Support At this point in time MurkWorks is unable to provide telephone support. We are keeping our product costs down by reducing the manpower that would be required to man a telephone. Hopefully this will change in the future. In the meantime, the best method for obtaining support is by sending us electronic mail to our Internet address: support@murkworks.com If you are on compuserve, you can send us mail using the address: internet:support@murkworks.com If you are not a licensed user, we may not be able to answer questions pertaining to installation problems or configuration issues. If you have found what you consider to be a problem with the FTPD NLM, please feel free to write to us with detailed information about the problem, your environment, and the commands issued which caused the problem. Be sure to include the current version number of the NLM when you write. You can always write to us: MurkWorks P.O. Box 631 Potsdam, NY 13676-0631 USA 22 Appendix A Sample Configuration File # Sample FTPD.CFG file for FTPD.NLM # # lines beginning with # are comments. maxconnections 5 # specify max # connections # forced to 2 or less in DEMO mode screendelay 2 # set delay in seconds between status # screen updates logfile sys:system\logfile.ftp # specify alternate logfile # The following lines are examples. Modify to # suite your needs and delete any remaining lines # that do not apply ##################################################### # DEFAULT CLASS # # The following class conditions will be used if # the incoming IP address (or name) doesn't match # any other class ##################################################### # The following class allows access to all users on # all servers accept for bkc (on any server). Once # connected, users may be idle up to 2 minutes, and # connected for at most 10 minutes. They can only login # mon-fri and they are only allowed readonly access class default deny */bkc settings connect 10, idle 2 + timerange mon-fri/0-23 + readonly 23 ######################################################### # CLASS DOM.MURK.COM # # The following class is used if the client IP address # is in subnet 20 # or any name ending in dom.murk.com ######################################################### # Access to all servers is denied, accept for access to # server GIMP, which allows all users. However users can # only login mon-fri between 10PM and 5AM, or # any time saturday and sunday class dom_murk_com address *.dom.murk.com address 113.121.20.* deny */* allow gimp/* settings timerange mon-fri/22-5 + timerange sat-sun/0-23 ########################################################## # CLASS MURKWORKS # # This class is used if the client IP address is in class # B network 113.121 or its IP name ends in murk.com # NOTE: Class dom.murk.com has precidence over this class as # appropriate since it is more specific ########################################################## # This class allows access to any user on THIS SERVER ONLY # All users except for bkc have readonly access and can only login # on weekends between 10am and 9pm # User bkc has access only on the weekends # In either case, all read/write operations will be logged to # the file vol1:usr\fred\logfile.ftp class murkworks address 113.121.*.* address *.murk.com deny */* allow * readonly timerange sun-sat/10-21 allow bkc timerange sat-sun/0-23 settings log 25 + logfile vol1:usr\fred\logfile.ftp 24 Appendix B Supported FTP Commands The following FTP commands are supported. Be aware that these are protocol level commands and are not necessarily the commands that a user would type at the command line of their client. USER PORT RETR ALLO PASS STOR CWD XCWD XPWD LIST NLST HELP QUIT MODE TYPE STRU ACCT NOOP RMD MKD DELE SITE The site specific command supported in this version is: SITE TP This command returns a list of trustee paths.